相信大家一定常聽到這句「名言」,不管是從老闆、從主管、或同事、甚至是有些開發方法如 MVP ,也提出類似的觀點。
在前三天了解基本概念後,可能有人會覺得奇怪:這句話跟 CI 有什麼關係呢?如果有仔細閱讀並思考前三天內容的話,大家應該猜想得到,魔鬼可能就在這句話的細節裡。這句話在軟體開發的世界裡,絕大多數的場景都沒錯,因為軟體開發在改善流程上,比起其他實體產業是非常快的。因此確實可以考慮早點進入市場,再求改善,甚至是原先沒有的功能都可以在未來改善時加入。咦?沒有的東西未來都可以加入的話,那一開始到底要「有」什麼呢?
這是今天想跟大家一起討論的:什麼才是「有」?
下面以 MVP 來當範例說明。
一般 MVP 是設計者先做需求假設,再提出解決需求的產品,只要目標使用後需求有被解決,就會持續使用產品。目標使用後,通常會有回饋給設計者,如果回饋跟設計者思考方向一致的話,設計者就能參考回饋再為產品加上更符合需求的功能;反之,代表一開始需求假設是錯誤的,設計者依然可以參考回饋,並思考下一個可行的產品。
舉個例子:假設醫院的病人會想利用網路來線上掛號,因此我們應該要有線上掛號產品來服務病人,病人使用覺得滿意,下次自然會願意繼續使用,或給一些回饋。不滿意的話,就不會繼續使用,甚至連回饋都懶得給。所以對最終使用者來說,毫無疑問地,一個「有」解決需求的產品,才能回饋設計者設計「好」產品。
而對設計者來說,什麼才是「有」?從上面的描述可以大概了解,對設計者而言,一個能解決需求的產品,並能提供回饋資訊的產品,就「有」了!
重點來了!試著思考一下,如果最終使用者所使用的產品,與設計者所預期的不同;或是更白話的:產品有瑕疵的話,會發生什麼事?
常見的就是 bug 回報,如醫院掛號時間與通知時間不符,這代表使用者的思考是符合設計者的概念;可怕的會是使用者用了有問題的產品後,但給予了錯誤回饋,這會讓設計者改善產品的方向錯誤。比方說:原本設計是送出表單前會再次確認,但實際產品沒有實做,使用者回饋也是正向居多,設計者會誤以為這是使用者接受的做法,於是思考改善流程或動線時,可能就會被忽略。
產品有瑕疵,會使團隊無法得到上述「先求有,再求好」的好處,甚至還會讓產品越改越差。
「先求有,再求好」,那什麼才是「有」?答案很明顯,正確的產品才是「有」,瑕疵的產品跟沒有一樣。在趕上線時,常會聽到「先求有,再求好」,這句話是對的,但把魔鬼細節加進去會更好:
「先要對,才會有,再求好」
趕上線的時候,要記得檢驗一下產品有沒有「對」。那要如何確保產品有對呢?這時 CI 精神就非常重要了!當團隊有了 CI 精神,團隊會常常對產品做驗證,不正確要立即修正,以確保交付出去是正確的產品,是對的,「才會有」!甚至,不但產品是正確地交付出去,在未來「再求好」的時候,常常驗證也能保護產品原本功能的正確。這才是真的「先求有,再求好」,也是這句名言與 CI 之間的關係!
Agile 有些方法也是確保交付的產品是正確的,如:
很多 Agile 方法的初衷,都是為了要確保產品正確。因此可以發現,其實 Agile 不只在講因應改變,同時也在講如何提升品質。當然, CI 也是!
未來在討論 CI 要領時,也會專注在「確保產品正確」,而上述的 Agile 方法都很適合拿來參考並使用。
這裡以企劃人員當範例,其他公司類似的職務可能像是 PM 或設計師等。
分工比較明確的公司,通常會分開發人員與企劃人員。開發人員的工作是產出正確的產品;而定義正確的產品,是由企劃人員決定。這會有類似 Dev 與 Ops 之間的衝突,但 See the whole ,從整體產品的角度來看,「確保產品,人人有責」,開發人員本來就需要了解什麼是正確的產品,企劃人員則應該要用各種方法讓開發人員知道,自己心中的正確產品。
所以什麼是非開發者的 CI ?一樣是 Continuous Integration ,持續整合資訊到開發人員上,並確認預上線產品或上線產品是否正確。整合資訊與確認的過程或多或少會有問題,比方說企劃人員沒發現新舊功能衝突,或開發人員誤會企劃人員的意思,但一樣 See the whole ,這都是要一起克服並解決的。更重要的是,這些都是本來就該做的事,不會因為不持續做,就可以不用做。持續做的好處是每次資訊同步與確認的量少,問題會比較明確好解決。
Dropbox 又來了:就像第一次同步 Dropbox 的檔案也會很久。當完成後,同步就會非常快速了。
下一篇:簡單的好習慣,是 CI 的一大步
「先求有,再求好」沒錯,但「先要對,才會有,再求好」會更好!
...
很有意思的主題
也是我們目前所使用的方式
"開規格"之前先開"粗規格"後立即寫 Code ,
再用 Code 呈現來驗證"粗規格"
再度 重寫"粗規格"
再用 Code 呈現來後再度驗證"粗規格"
到達滿意後
依據 Code 來寫"最終規格"
是的,這是規格精鍊的過程,所以非開發人員也必須要一起持續整合規格的資訊。
所以應該是「持續整合,人人有責」XD